The present invention relates generally to messaging systems, and more particularly to a multiple node messaging system wherein each node has shared access to the message stores of other nodes.
Messaging systems that provide voice, fax and/or e-mail messaging capabilities are well known. FIG. 1 illustrates an exemplary prior art messaging system developed by Unisys Corporation, the assignee of the present invention. The system of FIG. 1 comprises multiple servers (e.g., an A-series or Clearpath(trademark) computer offered by Unisys Corp.) each supporting a network applications platform (NAP), which provides an underlying platform for storage and retrieval of messages, and a messaging application running on the platform. A voice mail application, such as the Unisys Universal Voice Messaging System (UVMS), is an example of a messaging application that runs on the messaging platform. The UVMS application determines how calls to the messaging system are handled, what prompts are played to callers, and which features are available. Such applications typically maintain a database of subscribers who have xe2x80x9cmailboxesxe2x80x9d on the system. The messaging platform interfaces to a telephone network through a Network Interface Unit (NIU). Received messages are stored by the messaging platform in a local message store, or voice file.
Network Interface Units are available from a number of different vendors. For example, NIUs suitable for use with the present invention include: (a) the Telephony Services Platform available from Unisys Corporation, Blue Bell, Pa.; (b) the Summa Four VCO 80 available from Summa Four, Inc., Manchester, N.H.; and (c) the Voice Frame 2020 available from Harris Corporation, Melbourne, Fla. The Telephony Services Platform (TSP) is most preferred. The difference between it and the other products just mentioned is that the TSP includes a board that plays back digitized voice from a voice file whereas the other products require a separate playback module.
In use, if a subscriber is not available when an incoming call is received, the Public Switched Telephone Network (PSTN) forwards the call to the messaging system, which typically allows the caller to record a message, and then will store the message for later retrieval by the subscriber. A key (or token) will be returned to the messaging application that uniquely identifies the stored message data within the message store. This key can be used at a later time to retrieve the message from the message store for playback to the subscriber.
In the exemplary system shown in FIG. 1, a first node of the system comprises a server/NAP 10a, voice file and database 12a and NIU 14a. Similarly, a second node comprises a server/NAP 10b, voice file and database 12b and NIU 14b; and a third node comprises a server/NAP 10c, voice file and database 12c and NIU 14c. The first node could be responsible for a predefined geographic area encompassing hundreds of thousands of subscribers. For example, the first node could be responsible for a large area such as Northern California, the second node could be responsible for Middle California, and the third node could be responsible for Southern California. The respective nodes are separately coupled to a public switched telephone network, or PSTN, 16, and are thereby made accessible to their subscribers. Moreover, subscribers of one node can employ messaging to transfer copies of messages (such as voice messages) to subscribers of another node. The respective nodes, however, do not share access to each other""s voice files, databases or NIUs.
FIG. 2 depicts the structure of the voice files 12 and database. This structure is described in detail in U.S. Pat. No. 5,138,710, Aug. 11, 1992, xe2x80x9cApparatus and Method for Providing Recoverability in Mass Storage Data Base Systems Without Audit Trail Mechanisms.xe2x80x9d Briefly, each voice file is made up of a first database 12-1 (referred to as a Voice I/O Database, or VIODB) and a second database 12-2, which is referred to as the xe2x80x9cflat filexe2x80x9d in the ""710 patent. The VIODB 12-1 contains a series of records each of which includes a 48-bit (or 6-byte) message number (MN) and a series of pointers. Each pointer identifies a different voice message segment (VMS) in the flat file 12-2. Each VMS comprises 32,256 bytes of voice data and is associated with recovery data (RD) including the MN corresponding to that VMS, the number of bytes in the voice message segment with that MN, as well as other information.
The VIODB 12-1 is utilized to provide access to stored data in the flat file 12-2. In the embodiment disclosed in detail in the ""710 patent, each record in the VIODB 12-1 comprises a Message Number (MN), Sequence Number (SN), Segment Counter (SC), DB Number (DBN), Incomplete Message Flag (IMF), and Segment Descriptors (SD). The MN is a token used to identify and access messages. When a message is received by the system, a Message Number that is unique within the particular node is created and returned to the client application. The Sequence Number is utilized when a message requires more Message Segments (MS) than the maximum number of Segment Descriptors in a single database record. The Segment Counter indicates the number of Message Segments in a message. The DB Number is utilized to associate this message with a particular client application. The Incomplete Message Flag indicates that the message was not fully reconstructed during recovery of the database from the flat file 12-2 because of I/O errors. Each Segment Descriptor contains a pointer that contains an address (record number) of a Message Segment in the flat file and a field that indicates the number of bytes in the MS. The structure of the flat file 12-2 is based on each message comprising Message Segments stored as a record in the flat file at an address identified by the corresponding SD.
The recovery data (RD) is utilized to provide data integrity and could be used to recover the VIODB 12-1 in the event that it was damaged beyond repair such that it could not be recovered by database management algorithms. Moreover, the RD could be used if synchronization between the VIODB 12-1 and the voice file 12-2 is ever lost. This loss of synchronization could occur if the database VIODB 12-1 was not able to be fully recovered to the same point in time as the voice file. The RD comprises the following data items: an Available Marker (AM) indicating whether a MS is in use or available; a Self Pointer (SP) containing the flat file address of the containing MS; a Message Number (MN) that indicates which message the MS belongs to; a Segment Sequence Number (SSN) indicating the order in which the Message Segments were received; a Data Base Number (DBN) indicating which client application owns the MS; a Final Flag (FF) indicating that the MS is the last MS of a message; a Length (L) indicating the number of valid bytes in the MS; a Last Address (LA) pointing to the last MS of a message; and a Checksum used to verify integrity.
An important characteristic of a messaging system is that it be highly reliable and able to quickly recover from system failures. This characteristic is generally referred to as system xe2x80x9cavailability.xe2x80x9d The present invention relates to a messaging system architecture that comprises multiple redundant messaging nodes in order to achieve high availability. In other words, the present invention was developed in the process of designing a messaging system that would continue to provide access to messages stored in one disk file (say, voice file 12a) even while its corresponding host (server/NAP 10a) is inoperative. A related aspect of the present invention concerns the structure of the voice files. Although the voice file structure described above and depicted in FIG. 2 permits the messaging system to receive, store and retrieve high volumes of real-time data, it is not suited for use in a shared disk system of the kind employed in accordance with the present invention because the database 12-1 cannot be shared by multiple systems. Generally, a database cannot be shared because much of the database state is maintained in memory. A node reading the database (on disk) without access to the information in memory would get inconsistent information. Although one node, say 10a of FIG. 1, could act as a server for another node, say 10b, this would most likely not meet the real-time requirements associated with messaging systems. Moreover, it would make the nodes dependent (in this example, 10b would need to be operational for node 10a to be operational).
Even if the database issues could be solved, there would still be a problem with Message Numbers. Message Numbers are unique over all time, but only within a node. If multiple nodes are involved, the Message Numbers are not unique. Non-unique message numbers could allow the wrong message to be played out due to MN reuse.
Further background information concerning the construction and operation of messaging systems, and particularly systems employing a Network Applications Platform (NAP) for interfacing a telephone network and network applications running on an enterprise server, may be found in the following patents and copending patent applications:
U.S. Pat. No. 5,133,004, Jul. 21, 1992, xe2x80x9cDigital Computer Platform for Supporting Telephone Network Applicationsxe2x80x9d.
U.S. Pat. No. 5,138,710, Aug. 11, 1992, xe2x80x9cApparatus and Method for Providing Recoverability in Mass Storage Data Base Systems Without Audit Trail Mechanismsxe2x80x9d;
U.S. Pat. No. 5,384,829, Jan. 24, 1995, xe2x80x9cDigital Computer Platform for Supporting Telephone Network Applicationsxe2x80x9d;
U.S. Pat. No. 5,323,450, Jun. 21, 1994, xe2x80x9cTelephone Network Applications Platform for Supporting Facsimile Applicationsxe2x80x9d;
U.S. Pat. No. 5,494,606, Feb. 20, 1996, xe2x80x9cMulti-Lingual Prompt Management System for a Network Applications Platformxe2x80x9d;
U.S. Pat. No. 5,633,916, May 27, 1997, xe2x80x9cUniversal Messaging Service Using Single Voice Grade Telephone Line Within a Client/Server Architecturexe2x80x9d;
U.S. patent application Ser. No. 08/944,924, filed Oct. 6, 1997, xe2x80x9cEnhanced Multi-Lingual Prompt Management in a Voice Messaging System With Support for Speech Recognitionxe2x80x9d;
U.S. patent application Ser. No. 08/964,744, filed November 5, 1997, xe2x80x9cMethods and Apparatus for Providing External Access to Executable Call Flows of a Network Applicationxe2x80x9d;
U.S. patent aplication Ser. No. 08/987,571, filed Dec. 11, 1997, xe2x80x9cMultiple Language Electronic Mail Notification of Received Voice and/or Fax Messagesxe2x80x9d.
U.S. patent application Ser. No. 09/094,126, filed Jun. 9, 1998, titled xe2x80x9cUniversal Messaging System Providing Integrated Voice, Data and Fax Messaging Services to PC/Web-based Clients, Including a Session Manager for Maintaining a Session Between a Messaging Platform and the Web-based Clientsxe2x80x9d;
U.S. patent application Ser. No. 09/093,593, filed Jun. 9, 1998, titled xe2x80x9cUniversal Messaging System Providing Integrated Voice, Data and Fax Messaging Services to PC/Web-based Clients, Including a Content Manager for Receiving Information from Content Providers and Formatting the Same into Multimedia Containers for Distribution to Web-based Clientsxe2x80x9d;
U.S. patent application Ser. No. 09/094,266, filed Jun. 9, 1998, titled xe2x80x9cUniversal Messaging System Providing Integrated Voice, Data and Fax Messaging Services to PC/Web-based Clients, Including a Large Oject Server for Efficiently Distributing Voice/Fax Messages to Web-based Clientsxe2x80x9d; and
U.S. patent application Ser. No. 09/094,026, filed Jun. 9, 1998, xe2x80x9cSystem and Method for Integrating Notification Functions of Two Messaging Systems in a Universal Messaging Solutionxe2x80x9d.
A primary objective of the present invention is to provide an architecture for a highly reliable messaging system that is able to quickly recover from system failures. The present invention achieves this goal with a messaging system architecture that comprises multiple (at least two) redundant messaging nodes having shared access to each other""s voice files. In addition, the invention provides a new voice file structure that is suited for use with the inventive system architecture.
An exemplary embodiment of the present invention includes two nodes, with each node representing a complete messaging system, i.e., each node could function as a standalone messaging system. As discussed, multiple nodes provide redundancy to the architecture. According to the architecture of the present invention, each node maintains its own message store (also referred to herein as a xe2x80x9cvoice filexe2x80x9d) in which messages received by that node are stored. Each node thus has read/write access to its own message store. In addition, however, for purposes of achieving high availability, each node further has read-only access to the message stores of each other node in the system. Therefore, in this embodiment, any node can use its read-only access to the message store of a different node in order to play back a message from that message store. Because any node can play back a message stored on any other node, any node can receive and store messages for any subscriber. Therefore, messages can be stored across multiple nodes in a distributed manner.
Because it is often the case that a subscriber desires to delete a stored message once it has been played back, a node that uses its read-only access to play back a message from the message store of another node can also request that the other node then delete the message from its store. This is done via a xe2x80x9cDelete Requestxe2x80x9d issued to the node that xe2x80x9cownsxe2x80x9d the message store. Delete requests generally do not have the same real-time constraints as receiving or playing messages. Moreover, even if a delete request is not processed, a process known as xe2x80x9corphan reconciliationxe2x80x9d will rid the system of undesired messages. Orphan reconciliation compares the message numbers in the application database with those in the voice file. Any message numbers that are in the voice file but not in the application database are deleted.
According to an additional feature of the architecture of the present invention, in the event that one of the nodes in the system fails, one of the other available nodes can acquire read/write access to the message store of the failed node. In this way, the rest of the system can continue to use the available storage space in the message store of the failed node. The acquired read/write status can be maintained as long as necessary, e.g., until the failed node comes back on-line.
Yet another aspect of the present invention is that it is not necessary to duplicate messages on more than one node. Each stored message is uniquely identifiable across all nodes. This is achieved in the preferred embodiment by assigning a message number to each stored message that comprises a first part that identifies the particular disk file in which the message is stored and a second part that identifies the location of that message within the specified file.
Other features of the invention are described below.